DUDLFY KNOa crHOOl 

kj 1 / ; POSTGRADUATE bCHOUl 

m. :?£V --A 93943-5101 



NAVAL POSTGRADUATE SCHOOL 
Monterey, California 




THESIS 



SIMULATION AND PERFORMANCE ANALYSIS OF THE 
ZONE ROUTING PROTOCOL FOR TACTICAL MOBILE 
AD HOC NETWORKS 

by 

Kevin M. Shea 



September 2000 

Thesis Advisor: Murali Tummala 

Second Reader: Robert Ives 



Approved for public release; distribution is unlimited. 



REPORT DOCUMENTATION PAGE 



Form Approved 
OMB No. 0704-0188 



Public reporting burden for this collection of information is estimated to average 1 hour per response, including 
searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the c 
comments regarding this burden estimate or any other aspect of this collection of information, including sugges 
Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis F 
22202-4302, ar.J to the Office cf Management and budget, Paperwork Redticti:;* i 'reject (0704-0158) Washing 


the time for reviewing instruction, 
:ollection of information. Send 
dons for reducing this burden, to 
lighway. Suite 1204, Arlington, VA 
pon DC 20503 , 


1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED 

September 2000 Master’s Thesis 


4. TITLE AND SUBTITLE : 

Simulation and Performance Analysis of the Zone Routing Protocol for 
Tactical Mobile Ad Hoc Networks 


5. FUNDING NUMBERS 

N6600100WR00356 


6. AUTHOR(S) 

Shea, Kevin M. 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 
Naval Postgraduate School 
Monterey, CA 93943-5000 


8. PERFORMING 
ORGANIZATION REPORT 
NUMBER 


9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) 
SPAWARSYSCEN, D841 (Attn: Dr. North) 

53560 Hull Street, San Diego, CA 92152 - 5001 


10. SPONSORING 

/MONITORING 

AGENCY REPORT NUMBER 


11. SUPPLEMENTARY NOTES 

The views expressed in this thesis are those of the author and do not reflect the official policy or position of the 
Department of Defense or the U.S. Government. 


12a. DISTRIBUTION /AVAILABILITY STATEMENT 

Approved for public release; distribution is unlimited. 


12b. DISTRIBUTION CODE 


13. ABSTRACT ( maximum 200 words) 

This thesis presents a simulation and analysis of the Zone Routing Protocol (ZRP) for mobile ad hoc 
network (MANET) environments using the OPNET simulation tool. ZRP is being suggested for possible 
implementation in the Joint Tactical Radio System (JTRS) for the United States military. Utilizing a ZRP OPNET 
model that was developed at Cornell University, the analysis focuses on key performance parameters that include 
overhead generation, network adaptation, efficiency, and routing zone optimization. The ZRP model’s traffic 
monitoring has been enhanced for this work to identify the engineering tradeoffs between efficiency and performance. 
The results of this thesis provide valuable insight into the analysis and performance with varying zone routing radius, 
node velocity, and node density. Critical MANET environmental and simulation parameters required for JTRS 
implementation into the military battlespace have been studied. 


14. SUBJECT TERMS 

Joint Tactical Radio System, Mobile Ad Hoc Network, Optimum Network Performance, 
Protocol Analysis, Zone Routing Protocol 


15. NUMBER 
OF PAGES 

72 


16. PRICE 
CODE 


17. SECURITY 

CLASSIFICATION OF REPORT 
Unclassified 


18. SECURITY CLASSIFICATION 

OF THIS PAGE 

Unclassified 


19. SECURITY 
CLASSIFICATION OF 
ABSTRACT 
Unclassified 


20. 

LIMITATION 
OF ABSTRACT 

UL 



NSN 7540 01 280-5500 Standard Form 298 (Rev. 2-89) 



Prescribed by ANSI Std. 239-18 



1 



THIS PAGE INTENTIONALLY LEFT BLANK 



Approved for public release; distribution is unlimited. 



SIMULATION AND PERFORMANCE ANALYSIS OF THE 
ZONE ROUTING PROTOCOL FOR TACTICAL MOBILE 
AD HOC NETWORKS 



Kevin M. Shea 

Major, United States Marine Corps 
B.S., United States Air Force Academy, 1989 



Submitted in partial fulfillment of the 
requirements for the degree of 



MASTER OF SCIENCE IN ELECTRICAL ENGINEERING 



from the 



NAVAL POSTGRADUATE SCHOOL 
September 2000 



THIS PAGE INTENTIONALLY LEFT BLANK 



ABSTRACT 
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This thesis presents a simulation and analysis of the Zone Routing Protocol (ZRP) 
for mobile ad hoc network (MANET) environments using the OPNET simulation tool. 
ZRP is being suggested for possible implementation in the Joint Tactical Radio System 
(JTRS) for the United States military. Utilizing a ZRP OPNET model that was developed 
at Cornell University, the analysis focuses on key performance parameters that include 
overhead generation, network adaptation, efficiency, and routing zone optimization. The 
ZRP model’s traffic monitoring has been enhanced for this work to identify the 
engineering tradeoffs between efficiency and performance. The results of this thesis 
provide valuable insight into the analysis and performance with varying zone routing 
radius, node velocity, and node density. Critical MANET environmental and simulation 
parameters required for JTRS implementation into the military battlespace have been 
studied. 
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EXECUTIVE SUMMARY 



The Joint Tactical Radio System (JTRS) Acquisition Program was bom out of the 
the 1997 Quadrennial Defense Review (QDR), which called for the services to combine 
and integrate all tactical radio equipment. The essential premise behind this project is to 
leverage commercial off-the-shelf (COTS) and software defined radio (SDR) technology 
to produce a new family of tactical radios that are multi-functional and complete with 
advanced data networking capabilities to meet the needs of modem information warfare. 
The main objective of JTRS is to interconnect radios in a mobile ad hoc network 
(MANET). However, conventional routing protocols are unable to meet the unique 
requirements of MANET. Dynamic topology, bandwidth, power limitations, and limited 
physical security combine to make the MANET very challenging. The first generation of 
JTRS, the Digital Modular Radio, is being installed in the new Marine amphibious ships 
currently under construction. 

The Zone Routing Protocol (ZRP), developed at Cornell University, has been 
suggested for implementation in JTRS. ZRP incorporates a hybrid protocol which 
utilizes current Internet routing techniques combined with on-demand routing to reduce 
overhead and improve efficiency in MANET. ZRP forms a conventional Internet routing 
zone around each mobile node and only executes an on-demand routing protocol to meet 
out-of-zone destination requests. The routing zones of each mobile node provide the out- 
of-zone routing protocol a more efficient method of creating and establishing routes 
among mobile nodes. 

Utilizing an OPNET model of ZRP provided by Cornell University, this thesis 
studied and examined the protocol’s performance by developing a simple Marine tactical 
scenario. The focus of the analysis was on protocol overhead, network adaptation, 
efficiency, and optimization. Techniques and recommendations for future study of ZRP 
and other MANET protocols being considered for use in JTRS and DMR. The results 
provide a snapshot into the performance of ZRP in a simple network chosen to represent 
the relative scale of a single Marine rifle platoon operating in a one square kilometer area 
of operation. 

The overhead traffic generated by ZRP was consistent with that of a hybrid 
MANET protocol. By adjusting the size of the conventional Internet routing zone around 
each node, ZRP could be optimized for the Marine scenario. The amount of overhead 
generated by each mobile node’s routing zone was dictated by the size of its routing zone 
and was not impacted by mobile node velocity. The amount of overhead generated by the 
on-demand protocol for out-of-zone requests was dictated by the volume of traffic from 
each mobile node and the velocity of the mobile nodes in the network. Link performance 
was increased as the size of the routing zone was increased. However, the efficiency of 
the routing algorithm was decreased on a similar scale. The velocity of the mobile nodes 
had a detrimental effect on link stability. Previous techniques of optimization developed 
at Cornell University were also demonstrated along with the Marine scenario results. 

xiii 



The ZRP model utilized in this work did not incorporate several important 
MANET environmental factors to adequately model the JTRS battlespace. The power 
levels, source traffic, and antenna characteristics of each node need to be made ad hoc in 
nature. Furthermore, node movement should be reconfigured to provide formation 
movements to simulate tactical formations with appropriate movement and radio 
capabilities. Vehicle, foot, helicopter, and aircraft traffic could be represented by varying 
the velocity of some nodes. Foot mobile traffic could carry squad radios with limited 
transmit ranges and vehicles, helicopters, and aircraft could have greater transmitter 
coverage. One hundred or more MANET nodes are needed to accurately model the 
protocol behavior of ZRP. However, the Windows NT platform utilized for this work 
limited the numbers of nodes that could be placed in a scenario due to processing power 
limitations. 
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I. INTRODUCTION 



The Joint Tactical Radio System (JTRS) Acquisition program was bom out of the 
1997 Quadrennial Defense Review (QDR), which called for the services to combine and 
integrate all tactical radio development [1]. The essential premise behind this project is 
to leverage commercial-off-the-shelf (COTS) and software defined radio (SDR) 
technology to produce a new family of tactical radios that are multi-functional and 
complete with advanced wireless data networking capabilities to meet the needs of 
modem information warfare. The most aggressive objective of JTRS is the ability to 
form the radios into a mobile ad hoc network (MANET) [1]. The first generation of 
JTRS, the Digital Modular Radio (DMR), has been incorporated into Marine amphibious 
shipping currently under construction (LPD-17). 

Conventional routing protocols are unable to meet the unique requirements of 
MANET. Dynamic topology, bandwidth and power limitations, and limited physical 
security combine to make the MANET environment challenging [2], All facets of 
MANET exhibit ad hoc behavior; bit rates, quality of service (QoS), infrastructure, 
mobility patterns, and mobility characteristics [3], This wide range of operating 
configurations poses an enormous challenge to routing efficiency. Traditional shortest- 
path routing algorithms, such as the Distributed Bellman-Ford (DBF) algorithm, incur 
large update message penalties and exhibit slow convergence [3]. The requirement to 
reduce overhead and improve convergence has driven researchers to examine protocols 
with proactive path finding algorithms, which combine distance vector and link state 
approaches [3], On-demand discovery of routes can result in further overhead reductions 
compared to table-driven methods (e.g. link-state and distance vector), but suffer from 
latency due to route discovery delays. A hybrid combination of on-demand and proactive 
techniques has produced a more efficient routing protocol [2], 

The Zone Routing Protocol (ZRP), developed by Haas and Pearlman [4], 
incorporates a hybrid protocol that exploits the benefits of both reactive and proactive 
protocols and has been suggested for possible implementation in the Joint Tactical Radio 
System (JTRS) for the United States military [1], In ZRP, each node has a proactive zone 
around it, which is dictated by an adjustable zone routing radius. The zone routing radius 
is directly related to hop counts from the node. Routes outside the zone are determined 
by a reactive query that leverages the zone structure of the MANET using ZRP. The 
intent behind this MANET routing approach is to leverage routing knowledge in a 
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localized region and reach out to selected network nodes as opposed to flooding a 
network to locate a destination. 

The objective of this thesis is to study and analyze the Zone Routing Protocol 
(ZRP) for MANET environments using an OPNET simulation provided by Haas and 
Pearlman [4], The focus of the analysis will be on protocol overhead, network 
adaptation, efficiency, and routing zone optimization. Furthermore, the objective is to 
produce techniques and recommendations for future application of ZRP and other 
MANET protocols being considered for use in the JTRS and DMR. The results presented 
provide a snapshot into the performance of ZRP in a small generic network chosen to 
represent the relative scale of a single Marine rifle platoon operating in a one square 
kilometer area of operation. 

Chapter II begins with an introduction into the MANET environment and routing 
protocols. Hierarchical State Routing (HSR) and Temporally Ordered Routing Algorithm 
(TORA) are used to illustrate MANET protocols. The third chapter introduces ZRP and 
explains its method of operation. Chapter IV provides the reader with an understanding 
of the ZRP model and OPNET package used in this work. Chapter V presents the results 
of the simulation and analysis. Conclusions and recommendations are included in the 
final chapter. 
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II. MOBILE AD HOC NETWORK PROTOCOLS 



A MANET is a network environment where both the user nodes and the 
infrastructure itself are constantly in transition. There is no reliance on pre-existing fixed 
infrastructure, such as wireline backbone or network connectivity via satellite links. 
MANETs are intended to function independent of the fixed infrastructure with the 
exception of a few “stub” gateways to provide access to the larger network. Figure 1 
provides an illustration of the differences between MANET, traditional fixed 



MANET 



Mobile IP 



Fixed Network 




Figure 1. MANET Layer In Perspective (After Ref. [2]). 

Internet, and Mobile IP. The traditional fixed Internet is stable with little or no 
host/router mobility. Mobile IP attempts to give the hosts more mobility, but still 
requires a connection to the fixed network. As depicted in Figure 1, a MANET node is 
truly mobile and is itself a router with multiple wireless or wired connections. A 
MANET has four distinct characteristics, which together form unique underlying 
assumptions, design considerations, and concerns that are not revealed in static 
networking: dynamic topology, bandwidth constraints, energy constraints, and limited 
physical security [2], Communication protocols for this demanding environment must be 
adaptable, self-organizing, robust, and efficient enough to meet the constrained resources. 
Conventional routing protocols associated with a static, fixed infrastructure internet are 
unable to meet the unique requirements in a MANET environment due to considerable 
overhead and slow reaction to topological changes. 
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In a MANET, each node has a unique internet protocol (IP) address. Routers use 
a routing protocol to learn about the network and to determine the optimal path for 
sending a packet to a destination. The routing protocol functions at the network layer (see 
Figure 2) to perform this function. MANET protocols utilize the following basic services 
from the lower three levels: link status, packet delivery, and network layer address [2], 
The following sections will examine conventional and MANET routing protocols in more 
detail before looking at ZRP in Chapter EH. 



Application 

Transport 

Network 
Data Link 



Physical 



MANET ROUTING 
PROTOCOLS 



Figure 2. Typical Protocol Stack for MANETs. 

A. CONVENTIONAL ROUTING PROTOCOLS 

Conventional routing protocols use either distance vector or link-state algorithms 
to determine the most efficient path to a destination. Distance vector algorithms require 
each router to maintain a table with routes to all possible destinations along with an 
associated metric that is collected on a periodic basis. The routing overhead remains 
constant regardless of the amount of host movement. This type of method is closely 
associated with the distributed Bellman-Ford routing alogrithm. A version of Bellman- 
Ford is still being used today with the Router Internet Protocol (RIP). In RIP, for each 
entry the next hop to the destination is stored along with a metric to reach the destination. 
The metric can be based on distance, total delay, or the cost of sending the message [5]. 
Each node shares its internal information periodically through update broadcasts to 
neighboring nodes. The routers utilize the updates to constantly revise their routing 
tables for shortest-path calculations. Link-state algorithms operate in a similar manner 
but are event driven by changes in the link status of nodes. Path-finding algorithms 
provide a hybrid approach utilizing both distance vector and link-state algorithms [13]. 

Although distance vector and link-state algorithms are very effective for achieving 
routing optimization, the overhead associated with these techniques is considerable and 
exhibits slow convergence due to topological changes. A simulation study was conducted 
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by Lee, Gerla, and Toh [5], which analyzed RIP in a MANET and highlighted shortfalls 
of conventional routing protocols. In RIP, a conventional protocol, routing updates are 
produced on a periodic basis. According to the study, RIP does not scale well to large 
networks, because each network node requires N iterations to detect a node that is 
disconnected, where N represents the number of nodes. This is known as the count to 
infinity problem. On-demand protocols have clear proportional increase in overhead due 
to node mobility. Figure 3 depicts the overhead associated with periodic, on-demand, and 
hybrid protocols as a function of mobility. As clearly shown in Figure 3, the study 
determined that a hybrid proctocol is needed to meet the requirements of MANET. 



-a 

a 

O) 

JC 

u- 

0) 

> 

O 

OS) 

c 

*Z3 

3 

£§ 

OS) 

c 

CA 

Cl 

<D 

u* 

a 

c 



protocol with on-demand and periodic features 
constant periodic protocol 



pure on- dem and protocol 



Decreasing Mobility 



Figure 3. Behavior of On-demand and Periodic Mechanisms (From Ref. [6]). 



B. TABLE DRIVEN VS ON-DEMAND PROTOCOLS 



Two distinct types have emerged from the development of MANET protocols: 
table-driven and on-demand [7]. In table-driven algorithms, current routing information 
is maintained at each node. Table-driven algorithms are adaptations of the distance 
vector and link-state techniques. The constant routing updates, different types of tables, 
distributions, and techniques are used to increase efficiency. In contrast, on-demand 
protocols attempt to reduce overhead and are more responsive to MANET by having the 
source node dictate requirements. Routes are created on an as-required basis by the 
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source node. As depicted in Figure 3, a hybrid protocol combining both periodic and on- 
demand qualities responds to the needs of the network without creating excessive traffic 
overhead. All routes created, both on-demand and periodic, hold a time stamp to 
eliminate outdated routes. 

There are several types of MANET protocols being considered by the Internet 
Engineering Task Force (IETF) MANET Working Group that are table-driven (periodic) 
or on-demand. Some examples of table-driven MANET protocols are the Dynamic 
Destination-Sequenced (DSDV), Wireless Routing Protocol (WRP), Global State 
Routing (GSR), Fisheye State Routing (FSR), Hierarchical State Routing (HSR), Zone- 
based Hierarchical Link State Protocol (ZHLS), and Cluster Head Gateway Switch 
Routing Protocol (CGSR). DSDV is based on the classic Bellman-Ford algorithm. WRP 
is a table-based distance vector routing protocol. GSR is similar to DSDV, but takes the 
idea of link-state routing and improves it by limiting the flooding of table updates. FSR 
improves on GSR by limiting the size of update broadcasts. ZHLS is similar to HSR and 
divides the network into non-overlapping zones, but unlike HSR, there is no cluster head. 
CGSR is a combination of ZHLS and DSDV. Examples of on-demand MANET 
protocols include the Cluster Based Routing Protocol (CBRP), Ad Hoc On-Demand 
Distance Vector Routing (AODV), Dynamic Source Routing Protocol (DSR), Temporally 
Ordered Routing Algorithm (TORA), Associativity Based Routing (ABR), and Signal 
Stability Routing (SSR). GBRP combines the cluster technique with on-demand routing. 
AODV is a combination of DSDV and on-demand routing. DSR is an on-demand 
protocol initiated by the source node and focuses on route discovery and route 
maintenance. ABR defines a new routing approach with a metric based on link stability. 
SSR also defines a new metric approach based on node signal strength and location 
stability. HSR and TORA will be explained in the following sections to introduce a 
protocol from each category. 

1. Hierarchical State Routing (HSR) 

HSR combines the ideas of zone routing with a hierarchical structure and is 
clearly linked with conventional table-driven protocols. As depicted in Figure 4, nodes 
are broken up into routing zones at the physical network layer and selected nodes (cluster 
heads) become members of a virtual hierarchical tree similar to that in the Internet. 
Routing information is controlled in a tree data structure fashion. Each routing zone on 
the physical layer is tied together by a cluster head, which serves as the virtual leader of 
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the routing zone. The cluster head is periodically elected and collects all the routing data 
from the zone and distributes all the zone’s routes to other cluster heads on a virtual layer. 
The cluster heads provide the medium to share routing information in a hierarchical tree 
architecture. Selected cluster heads are promoted to higher levels in the tree data 
structure up to the root node and pass routing information among themselves on virtual 
layers. The cluster heads serve as the conduit to the upper and lower level cluster heads 
to ensure that all routing information is distributed to all levels. A gateway node is a 
node that resides in more than one zone and can communicate with nodes in both zones. 



Level 2 
Hierarchal 
Cluster Heads 



Level 1 
PeerCluster 
Heads with 
Gateway Nodes 



Level 0 

Physical 

Network 

Layer 




Figure 4. An Example of Clustering in HSR (After Ref. [7]). 



As shown in Figure 4, the nodes are partitioned into subnetworks (Level 0, Level 
1, and Level 2) according to the respective level in the hierarchical tree structure. A 
Location Management Server (LMS) handles address assignments for each subnetwork. 
Nodes that desire to operate in the subnetwork must register with the LMS to obtain an 
address. Each node is assigned a logical address <subnet,host> by their respective LMS. 
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The LMS functionality is similar to that of a Domain Name Server (DNS) in the Internet 
and shares information with other LMS to distribute routing information. 

2. Temporally Ordered Routing Algorithm (TORA) 

The Temporally-Ordered Routing Algorithm (TORA) was developed by Park and 
Corson and is presented in detail in a 1997 draft RFC [8]. It is a source-initiated, on- 
demand routing protocol proposed for dynamic mobile, multihop wireless networks. 
TORA is an adaptive, efficient, and scaleable distributed routing algorithm based on the 
concept of link reversal. The main feature of this protocol is the ability to localize control 
messages in a very small set of nodes which must respond to a change in network status, 
such as a link failure. This is accomplished by each node maintaining an extensive 
routing cache. The cache memory leads to scalability problems in large networks when 
memory requirements become excessive. The protocol is designed to work on top of the 
MAC layer that handles link status, packet delivery, link and network layer address 
resolution, and security authentication [8]. 

In TORA, the source node initiates the route creation since it is an on-demand 
routing protocol. The algorithm looks to build a directed acyclic graph (DAG) 
representing the relative heights of the routers with reference to the destination. Routers 
that are closer to the destination have a low height and are referred to as downstream 
nodes. Routers that are farther away from the destination typically have ever-increasing 
heights and are referred to as upstream nodes. Figure 5 presents an illustration of a 
directed acyclic graph formed when creating routes by relative heights of routers [9]. The 
height metric is maintained by an ordered quintuple (x, oid, r, 5, i) , where x is the logical 
time of a link failure defining a new reference level, oid is the unique ID of the router that 
defined the new reference level, r is a reflection indicator bit, § is a propagation ordering 
parameter, and i is the unique ID of the router [8]. 
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Step 1 

The 8 ounce brodcasts 
a query packet 




Step 2 

The destination returns 
an update packet. 




Step 3 

The update packet is broadcast 
back through the network, and 
node heights are set accordingly. 




Step 4 

The network converges 
with a directed graph. 




Figure 5. TORA Route Creation (From Ref. [9]). 

C. EVALUATION OF MANET PROTOCOLS 

There is no standard for evaluating MANET protocols. The IETF MANET 
Working Group recommends focusing on the fundamental tenets of MANET [2]. 
MANETs exhibit ad hoc behavior across the board. Bit rates, time constraints, reliability 
requirements/QoS, infrastructure, mobility patterns, and mobility characteristics (speed, 
predictability, and uniform) are all ad hoc in nature [3], Evaluation is even more 
challenging when one considers that mobile wireless assets will have limited range, 
packet loss, mobility loss, limited power, frequent network partitions, and security 
vulnerability. 
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The MANET Working Group emphasizes that each MANET Routing Protocol is 
well suited for particular MANET environments, and less suited for others. Each 
protocol should be evaluated in terms of advantages and disadvantages as opposed to one 
common test for all protocols [2], The Working Group identifies eight networking 
environment variables for examination: network size, network connectivity, topological 
rate of change, link capacity, fraction of unidirectional links, traffic patterns, mobility, 
and fraction and frequency of sleeping modes. Placing emphasis on intricate protocol 
comparisons is of limited value [7]. The results are often imprecise and make it difficult 
to compare algorithms with vastly different functionality in a precise, fair, and 
meaningful fashion. What is important is the average performance, which is only 
obtained through simulation. 

Metrics utilized for evaluation should be independent of the network protocol and 
both qualitative and quantitative. The Working Group identifies the following qualitative 
metrics: distributed operation, loop freedom, demand-based operation, proactive 
operation, security, sleep period operation, and unidirectional link support. Quantitative 
metrics identified are the following: end-to-end data throughput, delay, route acquisition 
time, percentage of out-of-order delivery, efficiency, average number of data bits 
transmitted divided by data bits delivered, average number of control bits transmitted/data 
bit, and average number of control and data packets transmitted divided by data packets 
delivered. 

The most important factor affecting performance is how well the propagation of 
redundant copies of a route discovery request by a mobile can be reduced to conserve 
memory cache [10]. An algorithm should recognize and discard identical requests and if 
a request has identified a route beyond a maximum length. The maximum length 
restriction serves to prevent infinite loops from occurring during discovery. However, 
aggressive route cache to enhance routing tables and the use of cache are critical 
parameters which prevent latency and unnecessary queries. 
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III. ZONE ROUTING PROTOCOL (ZRP) 



The ZRP protocol, developed by Haas and Pearlman [11], incorporates a localized 
zone approach to routing. The fundamental approach is to incorporate a hybrid protocol 
that exploits the benefits of both a reactive and a proactive protocol [12]. As depicted in 
Figure 6, each mobile node has a proactive routing zone around it that is dictated by an 
adjustable zone routing radius. The zone routing radius is directly related to hop counts 
from the node. In Figure 6, nodes D, C, F, B, and E are in Zone A with zone routing 
radius p = 2. Routes outside the zone are determined by an on-demand protocol query 
which bordercasts the out of zone query to the peripheral nodes (D, F, and E), which in 
turn, leverage the zone structure of the network to reduce query detection time. The intent 
behind this MANET routing approach is to utilize the routing knowledge in a localized 
region and obtain a route to a distant node on-demand. The following discussion on ZRP 
will focus on three major areas: Intrazone Routing Protocol (IARP), Interzone Routing 
Protocol (IERP), and routing optimization. 



A. INTRAZONE ROUTING PROTOCOL (IARP) 

LARP is responsible for maintaining routes within each node’s routing zone 
through periodic routing table updates. This is usually accomplished using a wide range 
of traditional distance vector or link- state protocols [3]. All nodes less than or equal to 




Figure 6. ZRP Example With Zone Routing Radius p = 2. 
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the routing zone radius are considered to be in the zone. These nodes are referred to as 
interior nodes. Nodes on the edge of the routing zone (those with hop count equal to the 
zone radius) are considered peripheral nodes and take on greater significance in the next 
section. Figure 6 depicts a typical zone centered around Node A with p = 2. The 
peripheral nodes reside at the outermost limit of the zone radius. In this case, D, F, and E 
are examples of peripheral nodes. 

Regardless of the reactive protocol chosen, it needs to be modified to keep the 
proactive traffic generation within the region of an individual node’s routing zone. For 
example, a split horizon version of the Distance-Vector Algorithm can be utilized for 
LARP. Although there are tradeoffs involved in LARP protocol selection, experience has 
shown that the overall performance of ZRP is not affected by this choice [4]. As shown 
in Figure 7, LARP relies on the Neighbor Discovery/Maintenance Protocol (NDM) to 
provide current status of a node’s neighbors. This NDM service is provided by the 
MAC/link-layer protocols. Overhead is not spared in the region for the sake of proactive 
discovery. Routing within each region should be fairly routine and not require much 
discovery effort outside of the proactive efforts. The overhead generated with this 
scheme is a function of the number of nodes in the routing zone (node density) and the 
zone routing radius [12]. Node density is a function of transmit radius. 
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Figure 7. ZRP Architecture (After Ref. [11]). 



12 



It is important to remember that the wireless nature of MANET can cause high 
zone populations despite a small hop count. As mentioned above, the physical coverage 
of the transmit antenna and the receiver density (per unit area) dictate the number of 
nodes in the zone (node density). The result is a significant increase in proactive LARP 
traffic and increased contention within the local zone [4]. Each MANET environment is 
characterized by the number of nodes N, node density 5, and relative node velocity v. 
The routing zone radius p ranges from the reactive region (p = 0) to the proactive region 
(p-»oo). The amount of LARP traffic per node (Tiarp) can be expressed by 

TiaRP = V X UiaRP / Neighbor 

where Uiarp is the number of IARP updates and Neighbor is the number of neighbors per 
node [4]. The amount of IARP traffic per node does not depend on the total node 
population, but it is a function of the the size of p. Neighbor is a function of both p and 8 
[14]. 

B. INTERZONE ROUTING PROTOCOL (IERP) 

Routing outside the zone is done based on a reactive or on-demand approach, by 
using IERP. Some of the functions of IERP including bordercasting, route accumulation, 
and query control, are performed by a special component of IERP called the Bordercast 
Resolution Protocol (BRP) (see Figure 7). IERP queries through the network, although 
global in nature, are expedited through the use of proactive routing zones. Instead of 
having to reach each node, the discovery process must merely touch each routing zone to 
discover the targeted node. When IERP queries are compared to a flooding mechanism, 
efficiency is increased and overhead is decreased by utilizing the zone topology of the 
network. The number of nodes queried (N q ) in the MANET is on the order of (0) 

Nq ~ CJ (Pzone/ Pnet) 

where p zone is the zone routing radius and p net is the network radius [13], 

The amount of route usage will vary due to applications and is expressed by two 
independent parameters: Riniuai-query and R r0 ute-usage [4]. Route stability is dictated by route 
lengths and is a factor of the span of the network, node velocity v, node density 5, and 
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zone radius p. Stability is expressed in terms of lifetime and is represented by its inverse, 
the average route failure (R r0 ute-faiiure)- The amount of IERP traffic (Terp) is represented 
by 



TlERP = TqN(p, 5) X Tquery 

TqN (P? 5) X N X ( Rjnitial-querv + Rsubsequent-queries) 



where T que ry is the rate of traffic queries, N is the number of network nodes, and T q N is 
traffic per queries per node and is a function of p and 5 [4], 

Routing failures are detected and repaired reactively by IERP. However, route 
failures can be detected by IP when a source route is determined to be unreachable. As 
shown in Figure 7, a route failure notification is usually provided by protocols, such as 
the Internet Control Message Protocol (ICMP). The repair process initiated by IERP is 
almost identical to the discovery process. IARP utilizes proactive route failure detection, 
which is triggered in response to a node leaving the source node’s zone by the NDM 
mechanism. 

1. Border Routing Protocol (BRP) 

Before examining the routing process, it is important to understand the structure 
of the localized nodes and the concept of bordercasting. As depicted in Figure 7, BRP is 
a subset and the workhorse of IERP. It provides bordercasting, route accumulation, route 
optimization, and query control [14]. As stated earlier, each zone is centered on a node 
and the size is dictated by the radius which can be modified for efficient routing in 
various types of networks [4], When a node must reach a destination outside of the zone, 
efficiency is increased by bordercasting the query request directly to the peripheral nodes 
to reach the entire network. BRP uses efficient flooding (multipoint relay) and efficient 
probing to control unnecessary overhead. It also does proactive route repair and route 
shortening to improve performance. This reduces the overhead in comparison to simple 
flooding over the entire network. IERP provides the route retrieval and route failure 
functions once the route is identified. 

Due to the extensive proactive discovery of IARP, a node can efficiently reach 
another node within the zone. As mentioned above, BRP provides the route optimization 
inside each zone [14]. When a node must be reached outside of the zone, this process is 
made more efficient by now exploiting the zonal topology of the network. With a quick 



14 



table look up, the node is able to first determine if the destination is within the node’s 
zone. Once this factor is eliminated, the query is quickly bordercasted to the peripheral 
nodes to initiate the broader search. The peripheral nodes’ neighbors cast to their 
respective neighbors not in the region, and each neighbor node is able to quickly 
determine if the prospective destination node is within its zone. If not found in the 
neighbor zone, the neighbor nodes in turn will bordercast across their zones, and the 
process continues until the destination node is located. Once the destination node is 
located, IERP returns the requested route to the source node which has been optimized 
by BRP using the proactive routing information stored in each zone by IARP. 

Figure 8 illustrates the discovery process used in IERP. Node A has a datagram 
to send to L. As depicted, L is not in A’s routing zone. Node A bordercasts (BRP) the 
route query to all peripheral nodes (D, E, F, and G). Each peripheral node, in turn, checks 
its routing table (IARP) for L and none of them have it. Each peripheral node now 
bordercasts (BRP) to its own peripheral nodes. For example. Node G conducts a table 
look up from its zone table (IARP) and is unable to locate node L. A bordercast (BRP) is 
initiated by node G, and K is able to check its table (IARP) and quickly respond (IERP) 
with the location of node L. The return route is identical to the query route. 



ZONE A 




DEST 



Figure 8. IERP Search with BRP (From Ref. [11]). 

ZRP does incorporate a query detection mechanism to reduce redundant queries 
and prevent it from degenerating to a flooding protocol [4]. ZRP offers two distinct 
methods of query detection for redundant queries and reduce overhead. Query Detection 
1 (QD1) allows the intermediate nodes to detect a redundant query and terminate the 
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thread. Query Detection 2 (QD2) allows all nodes to detect a redundant query and 
terminate the request. 

C. ROUTING ZONE OPTIMIZATION 

A mathematical expression for the optimum zone radius for optimum 
performance has not yet been determined [4], Even with perfect knowledge of all 
network parameters, computation of an optimal routing zone radius is not a 
straightforward mechanism. Haas [4] recommends that further research could focus on a 
complete derivation of the ZRP traffic function. As depicted in Figure 9, a simple 
approach is to adjust the zone routing radius until the setting for minimum ZRP overhead 
traffic is achieved. In the interim, two other schemes have been suggested for optimum 

Optimum Zone 




Figure 9. ZRP Zone Routing Radius Optimization. 



zone routing radius selection: min-searching and traffic adaptive method [4], Min- 
searching assumes that the node behavior will not change quickly over a period of time 
and an accurate assessment of ZRP traffic can be obtained. As shown in Figure 9, if 
IERP traffic is decreasing and the amount of proactive IARP traffic is increasing, there is 
an “undershoot” of the optimum zone radius. Likewise, if IERP traffic is increasing and 
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IARP traffic is also increasing would indicate an “overshoot” of the optimum zone radius. 
The traffic adaptive method only relies on current estimates. In this case, Haas [4] has 
shown that the amount of ZRP traffic generated is significantly higher when the ZRP 
traffic is dominated by the reactive IERP query traffic. The same is true when IARP 
traffic dominates. As depicted in Figure 9, the optimum region resides between these two 
regions. In other words, the ratio between EERP to IARP (IERP/IARP) should be as close 
one as possible for optimization. The general rule-of-thumb is that a sparse network 
favors a large routing zone and a dense network favors a small routing zone. 

D. SUMMARY 

Chapter III has presented the ZRP protocol and the three main component 
protocols: IARP, IERP, and BRP. ZRP establishes a routing zone around each node in 
the MANET environment. The size of each routing zone is dictated by an adjustable 
zone routing radius. Within each routing zone, IARP is responsible for maintaining 
routes through periodic routing table updates. All nodes less than or equal to the routing 
zone radius are considered in the zone. Routing outside the zone is done using a reactive 
on-demand protocol, IERP. BRP, a subset of IERP, provides bordercasting, route 
accumulation, and query control. IERP queries outside the zone are propagated by the 
use of the proactive routing zones defined in the MANET. ZRP optimization is achieved 
by balancing IERP and IARP overhead traffic. The optimum zone routing radius resides 
in the region where the ratio between IARP and IERP overhead is equal to one. The min- 
searching and traffic adaptive method are two alternative techniques for locating the 
optimum zone routing radius. 



17 



THIS PAGE INTENTIONALLY LEFT BLANK 



18 



IV. SIMULATION 



The simulation software used in this thesis was OPNET, Version 7.0 on a 
Windows NT platform. Pearlman’s ZRP OPNET implementation, developed in a UNIX 
environment, was the only MANET protocol available at the time of this work and was 
made available to the author. The UNIX based model was modified by the author 
through extensive collaboration with Pearlman [14] for implementation into a Windows 
NT environment. The OPNET package was chosen for this MANET protocol research 
due to its availability at the Naval Postgraduate School (NPS). Other popular simulation 
software packages used for MANET protocol simulation include ns2, PARSEC, and the 
C programming language. 

A. OPTIMUM NETWORK PERFORMANCE (OPNET) 

OPNET Version 7.0 can be used to simulate most standard network protocols and 
IEEE standards. For example, this most recent version has the ability to simulate IEEE 
802.11 for wireless networks. There is an extensive model library with easy to follow 
instructions and examples. However, MANET protocols are not yet standard with 
OPNET. The models can be broken down into three distinct levels as depicted in Figure 
10. The network layer depicts the network objects needed for network implementation. 
Each element (e.g., computer, bridge, router) in the network model is composed of a node 
model, which is further subdivided into node objects. For example, in Figure 10, udp, 
rsvp, ip_encap, and application are node objects of the workstation node model. The 
node object behavior is modeled by process models which actually contain the C code 
and OPNET specific kernel procedures. 

The C code and kernel procedures in an OPNET simulation are only executed in 
three locations which all reside in the process model states. As depicted in Figure 10, a 
stop sign-like icon represents a wait state. There are three types of states: initial, 
unforced, and transitional. The initial and unforced states appear as red stop signs and the 
transitional state appears as a green stop sign. Transitions form the connections between 
states. Within the stop signs, there are Enter Execs and Exit Execs where code is 
executed. As shown in Figure 10, the Exit Execs of the wait state appear in the lower 
right hand window. An unforced state will execute the Enter Execs code and return 
control to the processor while awaiting for a transition condition. Simulation time only 
expires between unforced states and processor handoffs. If a transition is identified in the 
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form of a code interrupt, transition code will be executed by the green transition states or 
by code resident in the transition link itself. For example, in Figure 10, a default 
transition condition forces a return to the wait state in the event of an unpredicted 
condition. 
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Figure 10. OPNET Simulation Methodology From Ref. [15]. 

B. ZRP MODEL 

The ZRP OPNET model is implemented by placing individual MANET mobile 
ZRP network objects, called manet_ls, in the workspace to create a network model. 
Figure 1 1 depicts a typical network model configuration manet_ls of network objects 
positioned in a workspace. Each manet_ls has behavior driven by the node model. The 
manetjls node model is depicted in Figure 12 and illustrates the various node objects 
required to implement manetjls : routing (routing), movement (move), transceiver 
(tx_simple and rx_simple ), MAC ( delivery and beacon), and traffic generation (app). The 
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node objects of manetjts are explained in further detail in the following sections. The 
number of manetjts ZRP nodes in the network model is limited to approximately 1000 
[14], The user is able to manipulate the following variables for each simulation: zone 
routing radius p in hop count, node velocity v in km/sec, transmit radius t r in km, and the 
duration of simulation (time units as appropriate). The node movement field is two 
dimensional and defined by an x_axis and y_axis entry (km). 
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Figure 11. ZRP Network Configuration. 



1. Routing and Traffic Generation 



As depicted in Figure 12, the routing node object is the key to the ZRP model’s 
routing performance. From routing, the traffic is passed to the appropriate-routing 
protocol for processing as explained in Chapter EH. IARP handles the in-zone traffic. 
IERP and BRP handle the out-of-zone traffic. Figure 13 is provided to illustrate the node 
object, routing, within manetjs. In this depiction, a query packet has arrived at routing 
after being routed to IARP (see Figure 14) to determine if the destination node was 
located in the source node’s routing zone. The destination node was not located in the 
routing zone so the routing mechanism passes the query packet to BRP (see Figure 15) 
for bordercasting which interacts with IERP (see Figure 16) to provide route 
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accumulation until the destination node is located. IERP provides the route reply 
notification to the source node. As the process model executes through the xmit transition 
state, the Enter Exec code depicted is executed, which records the amount of overhead 
traffic being generated to meet the query requirement. 




'r.ove 




Figure 12. Manet_ls Node Model. 



The beacon module is part of a neighbor discovery action which is typical of most 
MAC protocols and independent of ZRP [4]. The MAC neighbor discovery components, 
beacon and delivery , shown in Figure 12, were purposely included in manetjs to provide 
an ideal MAC behavior for comparison with various MAC protocols. The MAC layer 
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provides ideal scheduling of packet transmissions to avoid collisions. This feature allows 
for delays produced by various MAC protocols to be isolated. It has been shown that the 
MAC protocol has little effect on the overall performance of ZRP [4], The IARP traffic 
is generated based on a change in a neighbors status which is updated every 2Tb ea con (0-5 
seconds) for link status. The amount of IARP traffic is independent of the total network 
population and dictated by node density and the zone routing radius. IERP traffic is 
distributed on a uniform random traffic queries initiated by the app process model. 




Figure 13. Depiction of Routing Node Object Within ZRP_Manager. 
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Figure 14. LA.RP Process Model. 




Figure 15. BRP Process Model. 
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Figure 16. IERP Process Model. 



The simulation traffic is controlled by the model attributes of the app process 
model depicted in Figure 17. The number of total sessions (transmissions per 
simulation), packets per session, session interarrival delay, packet interarrival delay, 
mode (transceiver pipeline model), and destination, are manipulated from this window. 
The destination of each session (transmission) is usually set using a uniform random 
variable for delivery throughout the network. A single session can be setup between two 
nodes if the time to execute a single session exceeds the simulation time. This is 
accomplished by increasing the packets per session until time of delivery exceeds the 
simulation time. The simulation is interrupted before another session with a MANET 
node is initiated. This traffic channel analysis is only beneficial when using complex 
transceiver pipeline modeling which will be explained in the following section. 
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Figure 17. APP Process Model and Attribute Window. 

2. LINK ESTABLISHMENT 

OPNET simulates communication between two nodes through a process known as 
the transceiver pipeline. The transceiver pipeline models the transmission of packets 
across a communications channel (link). The OPNET package factors in the MAC layer 
attributes and includes multiple stages to model the channel’s behavior. Both the radio 
transmitter and radio receiver node objects ( tx_simple and rx_simple in Figure 12) include 
the following transceiver pipeline attributes: transmission delay, link closure (LOS), 
channel match, transmitter antenna gain, propagation delay, receiver antenna gain, 
received power, background noise, interference noise, signal-to-noise ratio (SNR), bit 
error rate (BER), error allocation, and error correction. 

The complexity of the transceiver pipeline was intentionally bypassed in the 
current model to simplify the communication simulation between ZRP MANET nodes 
[14]. Each mobile node utilizes a transmitter and receiver in direct delivery mode. The 
direct delivery attribute bypasses the transceiver pipeline options resident in OPNET and 
provides error free delivery to the destination node. Packet delivery fails only if a node 
moves out of range. An error free transceiver pipeline is assured if a destination node 
falls physically within the source node’s transmitter radius. The delivery node object 
handles this process through the tx_simple and rx_simple node objects depicted in Figure 
12. The simple implementation of tx_default and rx_default alone does not enable 
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OPNET transceiver pipeline modeling. It was determined by the author that further code 
and model modifications are necessary to interface with the transceiver pipeline model 
mechanisms. As explained above, with code and OPNET model changes, more complex 
link analysis could be used to create ad hoc transceiver pipeline and traffic generation. 

Inside the delivery node object, a packet _delivery process model provides the 
ideal MAC for the ZRP model [14]. The beacon module was specifically written for this 
simulation and handles neighbor discovery in a manner similar to most MAC protocols. 
The bits transmitted by the beacon module are not counted as overhead against the ZRP 
protocol since the MAC layer is present regardless of the protocol instituted. The 
txjdefault and rx_default allow for future interaction with OPNET transceiver pipeline 
modeling. The channel attribute setting in both txjdefault and rxjdefault can be 
manipulated to set data pipeline size. Due to an undetermined coding error in the ZRP 
model, 10 Mbps was used as the default channel rate. Troubleshooting indicated a 
pointer error caused by the function call, update_Detected_Queries_Table, which is 
depicted in Figure 18. The function call resides in IERP and is located in the Enter Execs 
of update jrequest. The corrective action taken was to comment the code out during 
execution and this was determined to not impact the model results with a 10 Mbps 
channel rate. 
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Figure 18. Pointer Error Correction to IERP Process Model. 

3. NODE MOVEMENT 

Node movement is simulated by the move node object depicted in Figure 12. As 
mentioned above, the user is able to input a uniform velocity in km/sec for all the 
MANET nodes from the simulation attribute window. At t = 0 sec, each node heads off 
on a direction assigned by a uniform random variable, in the range [0-27t], invoked by 
move. If a node impacts the edge of the virtual xy plane, it is detected by a transition 
condition in the move process model, a direction is recomputed in the range [0-2ti], and 
the mobile node continues to move about the virtual x-y plane. The animation attributes 
of OPNET depicting this random movement by selecting record animation from the 
project editor menu. A viewer window, m3_vuanim, can be deployed by selecting play 
animation following the execution of a simulation to view the random node movements. 
M3_vuanim uses a tape recorder like interface that can be manipulated to control the 
speed of node movements. 
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4. STATISTICS PRODUCTION 



Due to the cumbersome statistic collection methods of earlier versions of OPNET, 
a standard C code export file command, fprintf, was used in the ZRP model to collect 
statistics for analysis [14]. As the code executes, standard *.dat files are produced in the 
OPNET bin folder at the conclusion of each simulation. As explained earlier, although 
OPNET has inherent statistical collection, the standard node objects were not utilized 
throughout the ZRP model, so there is no connection with the inherent statistical 
collection of OPNET. The technique employed by the ZRP model is to use static 
variables declared in the process model code to provide the basis to gather statistics. The 
various process models have END_SIM states, which gather statistics during each process 
model execution call by the ZRP model. Figure 19 depicts the app process model which 
contains the END_SIM state for statistic production. This information traffic meter was 
added to the latest ZRP version to provide visibility to data throughput and efficiency 
[14]. The kevin_stat2 meter measured sessionsjsent, sessions_rcvd, packets. _sent, 
packets_rcvd, bitsjsent, bits_rcvd, total packet delay, and total jitter. MATLAB was 
utilized to organize collected data and produce results for analysis. Previous work on the 
ZRP model focused on ZRP overhead and had elected to neglect the traffic parameters 
[14]. 
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Figure 19. Example Of END_SIM Statistical Collection. 

C. SUMMARY 

This chapter has provided an introduction to OPNET Version 7.0 and presented 
the ZRP model which was converted to Windows NT from a UNIX implementation. 
OPNET uses the concept of workspace, network models, node models, node objects, and 
process models for network simulation. The behavior of mobile nodes using the ZRP 
protocol in a MANET environment is executed through the manet_ls node model. 
Routing routes traffic queries generated by the app process model to the appropriate 
IARP, 1ERP, and BRP process. Traffic delivery between nodes is ensured during each 
session (transmission) through the use of the direct delivery mode. Source traffic volume 
can be adjusted through the app attribute window. Move provides random movement and 
constant velocity to each node over the course of the simulation. Statistics were 
collected on each simulation through the use of the fprintf command executed in the 
END_S1M states of various process models and analyzed in MATLAB. A source traffic 
meter was added to the ZRP model for routing efficiency analysis. 
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V. RESULTS 



In this chapter, the results of the ZRP OPNET simulations with the Marine 
scenario are analyzed. The focus of this analysis was to evaluate the efficiency and 
reliability performance of the protocol. As discussed in Chapter IV, due to the hardware 
limitations of the Windows NT platform, experimentation was required to determine 
simulation parameters which could be evaluated within hardware constraints. Section A 
explains the scenario and configuration development process to meet these limitations. 
Previous research results from Hass and Pearlman [4] are utilized to provide a 
comparison with the results from this work and also illustrate ZRP behavior which could 
not be demonstrated with the Marine scenario. The traffic overhead generated by ZRP is 
presented in Section B by component (LARP, IERP, and BRP) to better understand the 
contribution from each sub-protocol which shapes the behavior and efficiency in a 
MANET environment. The first case examines ZRP overhead with changing zone 
routing radius. The second case examines ZRP overhead with changing velocity. Section 
C utilizes the same two situations to study the link performance of ZRP in the Marine 
scenario. This chapter concludes with an analysis of efficiency and routing optimization. 
Efficiency is measured against link performance to better understand the tradeoff between 
routing overhead and link performance. Using the Marine scenario as a case study, 
results of the min-searching and traffic adaptive methods of routing optimization are 
presented. 

A. SCENARIO 

The network configuration used in this scenario was designed to mirror the 
tactical use of JTRS by individual Marines. JTRS will provide the next generation of 
tactical radios for the warfighter. The network implementation was designed to emulate a 
Marine rifle platoon operating with a JTRS squad-level radio. Although a Marine rifle 
platoon operates with forty-two personnel, thirty-two nodes were utilized in this work, 
which provides a reasonable representation of this combat force. The number of nodes 
was kept to thirty-two to reduce the demand on the Windows NT platform’s limited 
computing power and to reduce simulation time. The 32 MANET nodes, modeled by the 
process model manet_ls, represent individual Marine rifleman with individual movement 
and data exchange capabilities. In a rapidly developing combat situation, each Marine 
would transmit and receive information to his fellow Marines for control and situation 
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awareness. As explained in Chapter IV, each MANET node moves individually across 
the x-y plane and communicates in a random fashion to mimic combat maneuvering and 
tactical data traffic. It is important to note that due to the limitations of the current ZRP 
configuration, the MANET nodes do not move in tactical formations. Each node is an 
independent random variable for both movement and traffic placed on the net. 

The x_axis and y_axis parameters for the simulation were configured to establish 
a 1 km x 1 km x-y plane to represent an operational area assigned to a rifle platoon. As 
depicted in Figure 1 1 , the MANET nodes were placed in a checkerboard fashion from the 
OPNET network editor window. From repeated experimentation with simulation 
parameters, it was determined that a 1 square-kilometer x-y plane produced a node 
density that balanced the requirement for freedom of movement and mobile node 
interaction. As explained in Chapter IV, each MANET node moves at a constant velocity 
in km per second. However, a platoon will not intentionally disengage from each other 
and will seek to preserve their tactical formations. In order to facilitate this behavior, the 
x_axis and y_axis parameters restricted movement to preserve unit integrity, command 
and control, and combat power. Experimentation further demonstrated that the 1 square- 
kilometer maneuver space served the purpose of preserving an average node neighbor 
density between 3-5 neighbors during the simulation with transmit radius t r = 0.2 km, as 
depicted in Figure 20. 




Figure 20. LARP Overhead with Changing Zone Radius (After Ref. [4]). 
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In order to provide a model reference and measure the amount of neighbor density 
driven by the scenario at various t r and p settings, the comparison between IARP traffic 
per node and average neighbor density was accomplished by utilizing Ref [4], which 
measured the IARP packets per node and related it to neighbor density. Neighbor 
density, the number of MANET nodes that a source node can reach in one hop, is 
primarily a function of transmit radius. Neighbors impact the population of a source 
node’s routing zone which dictates the amount of IARP traffic. The IARP meter, 
explained in Chapter IV, provides the feedback on each source node over the course of 
the simulation. From the data produced from the IARP meter, Figure 20 was produced to 
measure the average neighbors per node and IARP traffic per node (packets/sec). Figure 
20 illustrates the Marine scenario with t r = 0.2 km and t r = 0. 1 km compared with more 
dense ZRP simulations and larger x-y planes. As depicted, t r = 0.2 km provided between 
3 and 5 neighbors at zone routing radius of p = 1. For p > 1, the IARP traffic per node 
approaches a peak of 50 packets/seconds. This leveling effect is due to the small network 
size. As the p increases, its impact on the network is limited due to the small size of the 
network. With t r = 0.1 km, the IARP traffic was reduced due to with decreased neighbor 
density as a result of a smaller transmit radius. Simulation at t r = 3 km proved to be 
impractical for the Windows NT platform being utilized due to exponential simulation 
time increases as p was increased. As shown in Figure 20, the IARP traffic increases 
considerably as node density and p are increased in conjunction. The data points from 
Ref [4] in Figure 20 are provided to illustrate this behavior of ZRP in a MANET with a 
higher level of neighbor density that could not be modeled due to hardware limitations. 

Figure 21 illustrates the random movement of the nodes over the course of a 
typical simulation. The hollow circles depict the checkerboard starting positions 
displayed in Figure 11. At the conclusion of the simulation, the MANET node positions 
are recorded by the stars. From the final positions, clusters of nodes and network 
partitions are clearly visible. When MANET nodes cluster, the network is enhanced 
through multiple transmission routes. However, on the outer edges of the network, 
mobile nodes lack network stability and form a network partition which is completely cut 
off from the rest of the network. 
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Figure 21. Typical Scenario Movement Results. 



1. Configuration 

The ZRP model provided to the author was developed using earlier versions of 
OPNET (Versions 3.5 - 6.0) in a UNIX environment. As a result, the model had to be 
updated to OPNET Version 7.0 and some code changes had to be made to facilitate the 
implementation on a Windows NT platform. For instance, the variable M_PI is used by 
UNIX to represent the constant n and was not recognized by the Microsoft Visual C++ 
compiler linked with OPNET running on the Windows NT platform. The OPNET kernel 
procedure op_mko_all was used to force the conversion to Version 7.0. Multiple code 
modifications were required to manipulate the ZRP versions, code, and process models to 
achieve proper execution of the simulation. The most recent version of the OPNET ZRP 
model was utilized. This included the new IARP process model, IARP_ls, which 
executes a purely periodic proactive routing protocol. 

As explained in Section A, IARP traffic is directly related to node density and 
proved to be the pivotal barometer which established the scenario parameters that could 
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be modeled on the Windows NT platform for this analysis. A zone routing radius of p > 
1, x_axis = 1 km, y_axis = 1 km, and a transmit radius of t r < 0.3 km resulted in a 
reasonable IARP OPNET simulation event list requirement by tempering the neighbor 
density. Due to a programming decision, p = 0 cannot be directly entered into the 
simulation parameters of the ZRP model [14]. The ZRP model implementation requires a 
simulation parameter of p = 1 to simulate the p = 0 state. Therefore, p settings must be 
incremented by one in simulation window entry. The next version of ZRP will allow for 
a p = 0 entry. The neighbor density was determined to be acceptable at a transmit radius 
t r < 0.3 km and a simulation time of 15 minutes. The routing zone radius was kept at p < 
4 due to unreasonable simulation times above this threshold. The sessions per 
transmission (data transfers per transmission) was set to 1 to decrease transmission load. 
Session interarrival was not a factor in this case. Packet size is 1,000 bits and one packet 
was sent during each session (transmission). Since only one packet was transmitted per 
session, packet interarrival delay was not modeled. The channel data rate was set for a 
default 10 Mbps due to a memory error at lower data rates (see Link Establishment, 
Chapter IV for details). Based on the simulation parameters explained above and 
experimentation, it was determined that scenario simulation times were limited to 15 
minutes to keep OPNET simulation time to approximately 3 hours. For instance, OPNET 
required 2 days to simulate the Marine scenario with t r = 0.5 km, p = 3, and scenario 
simulation time of 15 minutes. 

B. OVERHEAD GENERATION 

From Chapter IV, the overhead generated by the ZRP was monitored by an 
overhead traffic meter placed in the process model of zrp_manager. Figure 22 illustrates 
the overhead generated by ZRP in bits/sec per MANET node over a 15 minute simulation 
of the Marine scenario with t r = 0.2 km, v = 0.2 km/hr, x_axis = 1 km, y_axis = 1 km, and 
p incremented from 0 to 4. Overhead is considered to be all IARP, EERP, and BRP data 
generated to provide routing functionality. IARP overhead is generated to provide in- 
zone routing and IERP/BRP is generated to provide out-of-zone routing. BRP overhead 
is equivalent to out-of-zone query requests due to its bordercasting and optimization role. 
IERP overhead is generated by route replies and route failure messages. As depicted in 
Figure 22, with a constant uniform node velocity and average neighbor density (primarily 
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dictated by transmit radius), the zone routing radius is the critical parameter dictating the 
amount of ZRP overhead that is generated. In this figure, the proactive routing overhead 
associated with IARP quickly increases as p is expanded. IERP overhead in bits/sec 
remains relatively constant and slowly declines as p is expanded. The low 1ERP 
overhead at p = 0 is dictated by traffic generation among MANET nodes [14]. An 
increase in traffic query demands would dictate an increase of IERP overhead at p = 0. 
IERP overhead steadily declines with increasing p as the IARP zone routing is able to 
respond to route query requests with its large route cache due to a large reactive routing 
zone. 

Figure 23 is used to illustrate the behavior of ZRP overhead (packets/sec) 
generated per node with increased zone routing radius. The zone radius that minimizes 
ZRP overhead can be experimentally determined. The simulation parameters for the 
Marine scenario are t r = 0.2 km, v = 0.2 km/hr, x_axis = 1 km, y_axis = 1 km, and p is 
incremented from 0 to 4. The Marine scenario is measured against Haas results to better 
depict the “U” shape of ZRP overhead in regions outside the capability of this scenario. 
At p = 0, ZRP overhead is driven by IERP packets per second required to meet traffic 
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requirements since LAJRP overhead is zero packets/sec in this region (see Figure 9). In 
Figure 22, as p increases, IARP overhead increases with zone routing radius. IERP 
overhead as a percentage of ZRP overhead is reduced due to the reactive zone cache built 
from proactive IARP routing. The result is an overall decrease in ZRP overhead as 
shown in Figure 23. As p continues to increase, IARP overhead traffic rises 
exponentially. As Figure 22 illustrates, IERP overhead continues to increase in this 
region due to link instability, but at a much slower rate when compared to IARP 
overhead. 




In addition. Figure 23 indicates that the Marine scenario does not show the 
downward trend in ZRP overhead per node. This is due to the low traffic generation rate 
and small scale of the MANET environment simulated by the Marine scenario to remain 
within hardware limitations. The Marine scenario also does not show a sharp rise in ZRP 
overhead as p increases and this is due to the limited number of MANET nodes. The 
ZRP overhead in the Marine scenario reaches a plateau of IARP traffic generation by p = 
4. The Haas scenarios of 500 and 200 node simulations are provided to illustrate this 
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behavior which could not be simulated. As p increases, more nodes are added to the 
zone, thus increasing the amount of IARP packets/sec per node. This example also serves 
to illustrate the earlier point that ZRP behavior is shaped by the MANET environment 
itself and ZRP performance will differ between MANET simulations. 

Figure 24 illustrates the advantage of a hybrid MANET protocol with respect to 
changing velocity. The simulation parameters used for the Marine scenario were t r = 0.2 
km, p = 2, x_axis = 1 km, y_axis = 1 km, and v is incremented from 0 to 0.8 km/hr. 
IARP is designed to be timer based and independent of event triggers (neighbor 




Node Velocity (km/hr) 



Figure 24. ZRP Overhead With Changing Velocity. 

discovery/neighbor loss). This is why the version of the time triggered IARP process 
model, IARP_LS_timer, utilized was critical. As depicted in Figure 24, the ZRP overhead 
remains relatively constant over the course of the simulation. The fluctuation is due to 
IERP that is impacted by node velocity, traffic generation, and link stability. IERP is 
responsible for maintaining routes during transmissions (sessions). The IERP variance is 
low since the simulation limited the number of packets/session in the configuration. With 
a large data channel, 10Mbps, the IERP route repair occurrences remained low. A 
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simulation with longer transmissions ( sessions ) with a smaller data channel rate between 
MANET nodes would have caused a rise in ZRP overhead. In this situation, the IERP 
overhead would force the curve upward due to the need to reestablish links, which were 
broken due to node mobility. The result is that ZRP overhead to support a MANET 
environment is independent of node velocity. 

C. LINK PERFORMANCE 

Figure 25 is provided to depict the link performance of ZRP as the zone routing 
radius is increased. A result reported by Haas is compared to the Marine scenario to 
provide scale with a larger MANET simulation with a higher level of average neighbor 
density. The Marine scenario represents a 15 minute simulation of the 32 node network 
with t r = 0.2 km, v = 0.2 km/sec, x_axis = 1 km, y_axis - 1 km, and p incremented from 
0 to 4. The Haas scenario illustrates a simulation of 1000 nodes at average neighbor 
density equal to five [4]. As shown in Figure 25, there is a correlation between link 
failures/sec and p. The Marine scenario records approximately 0.75 failures/sec at p = 0 
to approximately 0.62 failures/sec at p = 1. For p < 1, the failures/sec decrease steadily 
to 0.6 failures/sec. The flattening of the curve in the Marine scenario is due to the small 
scale of the network, which renders the routing zone increase less effective at large 
values. The decrease is a constant downward trend with network sizes of 1000 nodes and 
varies according to node density [4], Node density, the average neighbors per node, is 
dictated by transmit radius and is not a function of p. The downward trend in failures is a 
result of routing zone expansion which provides increased reliability. The ZRP 
mechanism which increases reliability is BRP. Instead of having to route through each 
node to the destination, BRP provides an optimum routing mechanism which exploits 
available IARP link-state information in each routing zone for optimization, thus 
decreasing hop count to destinations. The Haas example illustrates the impact of 
neighbor density that amplifies the routing optimization, which can be achieved from the 
proactive routing zone cache of IARP. Neighbor density is increased by increasing 
transmit radius of each MANET node. There is a difference of approximately 0.1 
failures/sec between the two cases until p = 2. This decreases the potential for link failure 
(route unable to be established) due to node movement, channel interference, and other 
factors associated with links between nodes. As a result of using ZRP, the link 
performance increases as the zone routing radius is increased. 
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The purpose of Figure 26 is to evaluate the impact of velocity on link performance 
with ZRP if the zone routing radius is held constant. The simulation parameters used 
with the Marine scenario for Case 1 were t r = 0.2 km, p = 2, x_axis = 1 km, y_axis - 1 
km, and v was incremented from 0 to 0.8 km/hr. At p = 0, the link failure percentage of 
the Marine scenario was approximately 57%. As the zone routing radius was increased, 
the failure percentage continued to rise. An increase in node velocity decreased the 
ability to maintain route stability. The time to transmit a message over the link becomes a 
problem due to shorter periods of route stability with increased node mobility. The 
deviation from this upward trend at v = 0.8 km/hr was unexpected. A repeat simulation 
with a different seed value, Case 2 on Figure 26, did not produce a large variation from 
the previous simulation. When the simulation was repeated at a lower neighbor density, 
Case 3 (transmit radius t r = 0.1 km), inconclusive results were observed. The link failure 
rate hovers at 95% with no distinct trends. The link failure percentage was expected to 
have increased with velocity in both situations. This does occur in both Case 1 and Case 
2 until an anomaly at 0.8 km/hr. Case 1, with transmit radius t r = 0.1 km, does not echo 
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this trend. At v = 0 km/hr, the link failure percentage is 94.66% and does rise to 96.22% 
at v = 0.6 km/hr. However, there is a decrease in link failure percentage at v = 0.4 
km/sec. The Marine scenario fails to produce a distinct ZRP behavior. 




Figure 26. Link Failure Percentage With Changing Velocity: Case 1, 2, and 3 With p = 2. 

D. EFFICIENCY AND OPTIMIZATION 

An important goal of this thesis was to look at the efficiency of this algorithm. 
Efficiency (rj) was measured as follows: 

r)= I /(I + OH) 

where I is the amount of information data bits and OH is the amount of overhead bits. At 
p = 0, ZRP is producing minimal overhead and is at maximum efficiency. As the zone 
routing radius increases, ZRP overhead increases rapidly due to LARP overhead which 
quickly decreases the efficiency. However, due to the small size of the Marine network, 
the decay quickly reaches a steady state. Figure 27 displays efficiency and link 
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completion percentage as a function of zone routing radius and depicts the tradeoff 
between efficiency and link performance. As discussed earlier, the ideal zone routing 
radius is when IERP and LARP traffic are balanced. From this diagram, from a pure 
efficiency standpoint we can determine that the ideal zone routing radius would be p = 1 . 
This zone routing setting would provide the least amount of inefficient routing with a 
large link completion percentage. All values of zone routing radius greater than 1 provide 
a marginal increase in link completion along with a decrease in routing efficiency. 




In accordance with the ZRP min-searching and adaptive traffic method of routing 
optimization discussed in Chapter ID, the optimal setting for the Marine MANET 
environment would be p = 1. Figure 28 displays routing zone optimization using the 
measurements at each interval. IERP only dominates in the p = 0 setting, where the ratio 
of IERP overhead to LARP overhead (IERP/IARP) goes to infinity since LARP traffic is 0. 
The closest setting to achieving balance between IERP and LARP traffic is at p = 1. The 
min-searching method assumes that the traffic of each node does not change drastically 
over time and would determine p opt in the following manner. Figure 22 is more 
applicable to this method. As depicted in Figure 22, starting at p = 0, the IERP traffic and 
LARP traffic are both on the rise. The undershoot situation is realized with IERP traffic 
increasing. At p = 1 , both IARP and IERP are increasing; this would be determined as an 
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undershoot region. For p > 1, IERP is decreasing and IARP is increasing which points to 
an overshoot situation. Therefore, p op i = 1 is forced by the adaptive traffic method. 




E. SUMMARY 

The Marine scenario configured for this analysis was hampered by a Windows NT 
platform which could only support 32 MANET nodes with an average neighbor density 
of 3-5 nodes. The Marine scenario failed to demonstrate the complete behavior of ZRP 
when compared to the results reported by Hass [4], This echoes the point that ZRP 
behavior will be different in various MANET environments. The overhead traffic 
generated by ZRP was broken down into component (IARP, IERP, and BRP) traffic. 
IARP overhead traffic provides the majority of routing traffic as the zone routing radius is 
increased. The amount of IARP traffic is a function of node neighbor density. The “U” 
shape behavior of ZRP overhead per node was not realized in the Marine scenario. The 
amount of traffic generated by the limited number of MANET nodes was not sufficient to 
mirror this behavior. ZRP proved to be relatively independent of velocity in the Marine 
scenario. Due to the low traffic generation rate, the variation in IERP overhead traffic 
was minimal. The ability to communicate does improve as the zone routing radius is 
increased. However, this effect became minimal at large zone routing radius values in the 
Marine scenario. The effect of changes in velocity on MANET nodes running ZRP 
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proved to be inconclusive. Despite varying the average neighbor density, no distinct 
behavior was identified. In the Marine scenario, p = 1 was proved to be the optimal zone 
routing radius by the min-searching and traffic adaptive methods. There was a distinct 
tradeoff between routing efficiency and link performance when adjusting the zone routing 
radius. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The results of this thesis provided a snapshot into the performance of ZRP in a 
small generic mobile ad hoc network chosen to represent a future JTRS architecture on 
the relative scale of a single Marine rifle platoon operating in a 1 square kilometer area of 
operation. The complete behavior of ZRP was not demonstrated in the Marine scenario 
due to the limited number of nodes (32), the low traffic generation , and the small x- and 
y-axis boundaries due to performance limitations of the Windows NT platform. Previous 
results reported by Haas and Pearlman were used as a rheostat to scale the results from 
the Marine scenario to the behavior of ZRP in that of a much larger network with 
MANET environment parameters outside of the capabilities of this work. 

The traffic overhead behavior of ZRP in the Marine scenario was consistent with a 
hybrid MANET protocol. With constant velocity and average neighbor density (primarily 
dictated by transmit radius), the zone routing radius proved to be the critical parameter 
dictating the amount of ZRP overhead generated in the Marine scenario. LARP overhead 
traffic increased rapidly as the zone routing radius is increased. The small size of the 
network forced the LARP traffic increase to level off when it would otherwise continue to 
increase in a larger network with greater neighbor density. IERP traffic overhead is 
driven by the traffic generation of the source nodes. IERP overhead traffic caused ZRP 
overhead fluctuations in the presence of changes in velocity. IERP is responsible for 
repairing routes, and this activity is slightly increased as a result of route instability 
introduced by velocity. However, the periodic behavior of LARP is independent of node 
velocity and was unaffected by adjustments to node velocity with the Marine scenario. 

ZRP link performance was improved in the Marine scenario by increasing the 
zone routing radius. When compared to previous research, a decrease is more continuous 
with network sizes of 1000 nodes and varies according to node density [4]. The 
variations in neighbor density could not be effectively measured due to the limitations 
with the Windows NT platform. The increase in link performance was diminished due to 
the small scale of the network simulation, which rendered the zone routing radius 
increase less effective at large values. The link performance of ZRP appears to be 
directly related to node velocity in the Marine scenario. However, the results were 
inconclusive. In general, as the node velocity increases, the ability to maintain link 
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stability decreases. The time to transmit a message over the link becomes a problem with 
increased velocity due to short periods of route stability. 

In accordance with the min-searching and traffic adaptive method of routing 
optimization, the optimal setting for the Marine MANET environment would be p = 1. 
IERP only dominated in the p = 1 setting where the ratio of IERP/IARP goes to infinity 
since the LARP traffic is zero in this region. The closest setting to achieving balance 
between IERP and LARP traffic is at p = 1 . The Marine scenario demonstrated that ZRP 
is able to adapt to MANET environments through adjustments to the zone routing radius. 
Analysis relating link completion with zone efficiency produced an intersection point 
prior to the optimum zone radius. In the Marine scenario, the small size of the network 
produced flat curves once the zone routing radius exceeded 1 . However, this technique 
may prove to be unreliable in a larger network since network performance and network 
efficiency would continue to rise and fall, respectively. 

B. RECOMMENDATIONS 

The scenario configured for protocol analysis is critical to accurately model a 
MANET protocol’s behavior. Future studies of ZRP or other MANET protocols should 
incorporate simulations that are able to model a larger set of MANET nodes in a larger x- 
y plane. The author suggests using at least 100 nodes or more. Neighbor density level 
limitations due to computer hardware should reduced for future research. A small 
network was not sufficient to model all aspects of ZRP behavior. Traffic generation from 
the MANET nodes should be elevated to better model the IERP overhead behavior for 
small zone routing radius values. The larger traffic flow will also provide better feedback 
on the behavior of ZRP in regions of changing velocity. During each session 
(transmission), multiple packets should be transmitted to provide data on packet 
interarrival delay over the MANET network. The data rate of the channel should be 
reduced significantly to resemble more realistic levels. Third generation cellular 
networks will have 2 Mbps throughput. Marine Corps tactical radios currently are only 
capable of 9.6 kbps. 

The ZRP OPNET model utilized in this work does not incorporate several 
important MANET environment factors in its current form. Power levels, ad hoc traffic, 
formation movements, transmit radius, and ad hoc velocity would more accurately model 
the military battlespace for JTRS implementation. Battery power remains a critical 
concern to the tactical radio operator. The LARP process should be modified to 
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incorporate a low power indicator for each mobile node. The BRP should be able to 
leverage this proactive data in the route optimization process. The node movement 
should be modified to create association, so groups of nodes could move about the 
battlespace. This group behavior would further improve the capability of the ZRP 
protocol. The group behavior would provide more consistent neighbors throughout the 
simulation and mirror real world tactical formations. Furthermore, the speed of each 
node or groups of node should be made ad hoc to further enhance the realization of the 
tactical scenario. Vehicle, foot mobile, helicopter, and aircraft traffic could be 
represented by varying the velocity of some nodes. Ad hoc transmit radius capabilities 
would provide a more realistic battlespace model. Foot mobile traffic would carry 
limited range squad radios. Vehicles, helicopters, and aircraft would have significantly 
larger ranges and bridge the battlespace. 

ZRP is a simple hybrid MANET protocol that has a great deal of potential for 
JTRS. However, more in depth study and analysis is required to explore its capabilities. 
Comparison of ZRP with other MANET protocols over identical simulations should 
provide the level playing field for evaluation. It is hoped that this thesis has provided 
insight into the ZRP protocol and its potential application to a small ad hoc mobile 
network operating in a tactical environment. 
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